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Beschreibung 

Verfahren zur Vergebiihrung eines Dienstes in einem Kommunika- 
tionsnetz 

5 

Problemstellung der Erfindung 

In einem paketorientierten Kornmunikationsnetz mit Dienstan- 
wendern (z.B. SIP-Clients) , Diensterbringern (z.B. Applikati- 

10 ons-Servern) und einem vermittelnden Applikationsbroker (z.B. 
SIP Proxy) r der fur die Dauer der Servicebeziehung zwischen 
einer Dienstnutzereinrichtung (Client) und einem Application 
Server nicht in diese Beziehung eingebunden ist, (d.h. z.B. 
kein Stateful SIP-Proxy) , ist es fur den Proxy unmoglich eine 

15 zuverlassige Vergebiihrungsfunktion fur registrierte Kunden 
(Anwender und Diensteanbieter) bereitzustellen. 

Bisherige Losungen der Problemstellung 

20 

Proxy bleibt in der Kommunikationsbeziehung fur die Dauer 
der Servicebeziehung (Stateful Proxy) , oder 
- Vergebiihrung lauft separat zwischen Application Server und 
Client ohne Einbeziehung des Proxies , d.h. der Betreiber 

25 des Proxies ist ausschliefilich Access-Provider. Eine Ge- 

samtrechnung aus einer Hand auch fur in Anspruch genommene 
Dienste lassen sich - wenn uberhaupt - dann nur mit grofcem 
Aufwand im Postprocessing erreichen -> Verteilte Billing- 
funktionen beim Proxy-Betreiber und beim Application Ser- 

30 ver Provider. Diese Losung erfordert zum einen die Sicher- 

stellung, dafi der Nutzer eines Services auch gleichzeitig 
Kunde von Proxy- und Serverbetreiber ist, und zum anderen 
die Ubermittlung von Daten an den zentralen Rechnung- 
sersteller . 

35 
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Losung der Problemstellunq gemafl der Erfinduncr 

Die Erfindung beschreibt ein Verfahren, wie in einem derarti- 
gen Scenario mit Client , Proxy (=Applikationsbroker / Applika- 
5. tionsvermittlungseinrichtung). und Applikations server eine fur 
alle Partner zuverlassige Vergebiihrung erreicht werden kann, 
die zudem fiir den Anbieter (Provider) des Grunddienstes 
(Betreiber des Proxy) einen Mehrwertdienst darstellt. Dieser 
Provider ist damit in der Lage, seinem Endkunden eine zuver- 

10 lassige Rechnung aus einer Hand mit paketorientierten Diens- 
ten von unterschiedlichsten Partner-Serviceprovidern anzubie- 
ten. Dabei kann der Grunddienstanbieter sowohl als einfacher 
Vermittler eines Dienstes, als auch als Zwischenhandler mit 
"Rebranding" auftreten (Unter "Rebranding" wird hierbei ver- 

15 standen, dass der Betreiber des Proxy einen Dienst eines 

Partner-Serviceprovider nicht unter dem urspriinglichen Namen 
des Dienstes sondern unter einem eigenen Produktnamen anbie- 
tet) . 

20 Letztendlich ist der Zweck dieses Verfahren, 

a) Registrierten Endkunden (Clients) mit einem Guthabenkon- 
to in Echtzeit Nutzungsgebiihren fiir angeforderte und ge- 
nutzte Dienste zu verrechnen, oder 

b) Registrierten Endkunden regelmaBig (z.B. monatlich) eine 
25 einheitliche Gesamtrechnung fur alle genutzten Services 

von unterschiedlichen Providern zu erstellen. 

4 

Mit dem Verfahren wird sichergestellt f dass 

a) der Kunde nur das bezahlt, was er nutzt f und 
30 b) der Diensterbringer fiir seine Leistungen bezahlt wird. 

Daneben schafft dieses Verfahren die Voraussetzung dafiir, daft 
dem Kunden als Option schon wahrend der Dienstenutzung in Re- 
alzeit angezeigt werden kann, welche Gebiihren fiir den Dienst 
35 aufgelaufen sind, bzw. bei Prepaid-Service, wie viel Guthaben 
noch vorhanden ist. 
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Grundlage dieser Losung ist eine zuverlassige Vergebiihrungs- 
funktion, in die alle Partner -Komponent en (Client, Proxy / 
Application Broker, Application Server) _ wahrend der Dienste- 
nutzung eingebunden sind. 

5 

Client : Authentif iziert sich beim Proxy und fordert Dienst 
an. 

Proxy / Application Broker : Vermittelt Dienst und fuhrt Buch 
iiber die Nutzung dieses Dienstes durch den Client. 
10 Application Server : Bietet Dienst an und informiert mit Ti- 
ckets den Proxy uber Zustandekommen und Verlauf der Service- 
beziehung zwischen ihm und dem Client. 

Abbildung 1 beschreibt bei einer Realisierungsvariante der 
15 Erfindung die Beziehungen der Partner-Komponenten untereinan- 
der und den prinzipiellen Ablauf von der Authentif izierung 
des Clients uber die Dienstanforderung und Diensterbringung 
bis hin zur Vergebuhrung. 

- Nachdem sich der Client mithilfe des Proxy bei dem Authen- 
2 0 tif ication-Authorization-Accounting-Server (AAA-Server ) 

authentifiziert hat (l)/(2) erhalt er von dem Proxy zusam- 
men mit der Angabe, wo sich der Application Server befin- 
det (Destination) eine Billing-Reference (pi) , die vom 
Proxy zur Ausubung der Vergebuhrungsf unktion fur die an- 
25 stehende Dienstnutzung generiert wird (3) . 

- Der Client fordert mit der Information, die er vom Proxy 
erhalten hat, beim Application Server den gewunschten 
Dienst an (4) . Dieser bestatigt die Dienstanforderung an 
den Client (5) . Hiermit ist die Servicebeziehung zwischen 

30 Client und Application Server eingerichtet . 

- Nachdem die Servicebeziehung zwischen Client und Applica- 
tion Server aufgebaut worden ist, und solange der Dienst 
genutzt wird, erstellt der Application Server in regelma- 
Bigen Abstanden (z.B. 1 pro Minute) Tickets, die an die 

35 Vergebuhrungsf unktion auf dem Proxy gesendet werden (6) . 
Diese Tickets enthalten die Reference pi, die dem Proxy 
erlaubt, effizient auf die Vergebiihrungstabelle (Billing- 
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Tabelle) zuzugreifen, und die Reference si, die der Server 
selbst erstellt hat, und mit welcher er gegebenenfalls 
spater bei einer Ruckmeldung vom Proxy effizient auf seine 
Daten zugreifen und eine bestehende Service Relationship 
5 beenden kann.. 

- Nach Erhalt eines Tickets (6) ermittelt der Proxy anhand 
der in dem Ticket enthaltenen Reference pi den Client (IP- 
Adresse CI) und fordert von diesem fur jedes empfangene 
Ticket eine Bestatigung dieser Vergebiihrungs daten an (7) . 

10 Falls nach einer bestinntiten Zeit (z.B. 1 Sekunde) die Bes- 

tatigung nicht empfangen wurde, wird die Anforderung (7) 
ein- oder zweimal wiederholt. 

- Nach Empfang der Bestatigungsanf oirderung verifiziert der 
Client das Ticket und sendet gegebenenfalls eine Bestati- 

15 gung an den Proxy (8) . 

- Nach Empfang einer Bestatigung vom Client speichert der 
Proxy das Ticket zu einer spateren Rechnungserstellung ab 
(9) und informiert den Server, dass der Client das Ticket 
bestatigt hat. Im Falle eines Prepaid-Kunden aktualisiert 

20 die Vergebiihrungs funkt ion auf dem Proxy den Guthabenstand 

des Kunden. 



25 



Sonderfalle bei der beschriebenen Realisierungsvariante der 
Erfindung: 

30 - Prepaid-Kunde : 

Wenn das Guthaben eine bestimmte Schwelle unterschreitet 
informiert der Proxy den Client, dafi das Guthaben fast 
aufgebraucht ist. Dies kann z.B. mit der nachsten Anforde- 
rung einer Bestatigung fur ein Ticket erfolgen (7) . Falls 

35 das Guthaben aufgebraucht ist, wird der Proxy den Eintrag 

in der Billing Table loschen und weitere Tickets vom Ap- 
plication Server fur diesen Kunden nicht mehr akzeptieren 
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und diese Tickets dem Server negativ quitieren, woraufhin 
dieser die Servicebeziehung zum Client gegebenenfalls be- 
enden wird. 

5 - Anforderung einer Ticketbestatigung (7) vom Client negativ 
quitiert : 

Der Proxy informiert den Application Server, dass ein Ti- 
cket negativ quittiert wurde, wobei er dem Application 
Server die Reference si zuriickgibt. Anhand der Reference 
10 si ist der Server daraufhin in der Lage, die Servicebezie- 

hung zum Client zu beenden. 

- Ticketbestatigung vom Client trotz mehrmaliger Anforderung 
nicht erhalten: 

15 Der Proxy informiert den Application Server , dass er fur 

ein Ticket keine Quittung vom Client erhalten konnte, wo- 
bei er dem Application Server die Reference si zuriickgibt. 
Anhand der Reference si ist der Server daraufhin in der 
Lage, die Servicebeziehung zum Client zu beenden. 

20 

- Timer tl fur Billing Table Eintrag lauft ab. 

Um die Gultigkeit eines Billig Table Eintrags zu sichern, 
uberwacht der Proxy den Eingang der Tickets vom Server. 
Sobald ein Ticket (6) eintrifft, wird der eingestellte Ti- 
25 mer zuriickgesetzt . Bei Ablauf des Timers wird der Eintrag 

in der Tabelle geloscht. Evehtuell nachfolgend eintreffen- 
de Tickets vom Server werden negativ quittiert. 



30 Berne rkungen : 

- Zu beachten ist, daB dieses Verfahren nicht erfordert, 

dass Server und/oder Client sich bei Beendigung der Servi- 
cebeziehung beim Proxy abmelden. So erfolgt auch die 
35 Versendung eines Vergebiihrungstickets an den Client immer 
im Voraus fur das aktuelle Vergebuhrungsintervall. Damit 
ist sichergestellt, dafi der Client nicht kostenpflichtige 
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Dienste in Anspruch nimmt, ohne dass er dafur bezahlt, in- 
dem er vor Ablauf eines Vergebuhrungsintervalls einfach 
den Dienst abbricht, um zu verhindern, dass er fur das 
vergangene Intervall vergebiihrt wird. 

Der Uberwachungs timer tl in der Billing Table muss auf je- 
den Fall groBer als die Lange des Vergebuhrungs intervall 
sein, das zwischen Client und Application Server verein- 
bart wird. Es muB groJi genug gewahlt werden, um zu vermei- 
den, dass eine verloren gegangene (und deshalb vom Server 
wiederholte) Ticketnachricht an den Proxy dazu fiihrt, dass 
dieser den Billing Table Eintrag fur ungultig erklart. 
Gleichzeitig darf tl aber nicht zu groB gewahlt werden, um 
zu vermeiden, dass beispielsweise Denial-of-Service Atta- 
cken von boswilligen Clients zu einer Verknappung der Bil- 
ling Table Resourcen und letztlich zu einer Nichtverfiig- 
barkeit dieser Dienste fuhrt. Ein vernlinf tiger Wert fur tl 
ist 2-3 Mai die Lange des Vergebuhrungsintervalls, Da die 
Lange der Vergebuhrungsintervalle der einzelnen Servicebe- 
ziehungen (siehe Abb. 1) unterschiedlich sein konnen, wird 
die Lange des Uberwachungstimer tl variabel gestaltet. So- 
bald der Proxy ein Ticket vom Server erhalt, verwendet er 
die darin angegebene Lange des Vergebuhrungsintervall und 
bestimmt daraus die Lange von tl, um den Empfang des 
nachsten Tickets vom Server fur diese Servicebeziehung zu 
uberwachen. Bis zum Empfang des ersten Tickets vom Server 
wird ein fur die Billing Table einheitlicher fester Initi- 
alwert fur diesen Timer verwendet (z.B. 5 Sekunden) . 
Mogliche vertrauensbildende MaBnahmen zwischen Client und 
Application Server: Die Konditionen fur die Servicebezie- 
hung (Lange und Kosten des 1. Intervals , Lange und Kosten 
der Folgeintervalle) werden zwischen Client und Server 
vereinbart. Durch die Wahl eines kurzen 1. Intervals und 
ggf. Sonderkonditionen dafur kann sichergestellt werden f 
dafi auch im Falle einer Nichterbringung der Leistung (z.B. 
Serverausfall, SW-Fehler f Inkompatibilitat von Client und 
Server software) trotz aufgebauter Servicebeziehung ftir den 
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Dienstanwender kein Oder nur ein geringer Nachteil ent- 
steht . 

- Bei Ausfall der Vergebuhrungsfunktion des Proxies kann der 
Application Server aufgrund der ausbleibenden Quittung auf 

5 das Ticket die Servicebeziehung zum Client gegebenenfalls 

abbrechen. 

- Bei Ausfall des Clients wird das Gebiihrenkonto des Kunden 
nicht falschlicherweise weiter vom Server belastet, da 
Client nicht mehr in der Lage ist, weitere Ticketbestati- 

10 gungsanforderungen des Proxy zu quittieren (siehe Sonder- 

falle) . 

- Funktionalitat beim Client erweiterbar z.B. um 

i. Kumraulierung der vom Proxy ubermittelten Gebiihrennach- 
15 richten und Anzeige dieser Gebiihren am Terminal zur Ge- 

buhren-iiberwachung in Realzeit. 
ii. Moglichkeit fiir Endbenutzer als Option Tickets manuell 
zuriickzuweisen f z.B. bei Erreichen eines bestimmten 
selbstgesetzten Gebiihrenlimits . 

20 

Zusammenfassend kann folgendes gesagt werden. Das beschriebe- 
ne Verfahren erlaiobt dem Betreiber eines Stateless Proxy bzw. 
Application Brokers auf einfache Art und Weise registrierten 

25 Application Service Anbietern und registrierten Kunden eine 
zuverlassige, in def inierbaren Intervallen genaue und ver- 
trauenswiirdige Vergebuhrungsfunktion anzubieten f indem sich 
wahrend der Diensterbringung Client und Server standig im 
Hintergrund in regelmafiigen Abstanden iiber einen unabhangigen 

30 Dritten (Proxy) iiber die dafur anfallenden Geblihren verstan- 
digen und die Vergebuhrungsfunktion auch von dem unabhangigen 
Dritten erbracht wird. 



35 Anwendungsbeispiele der Erfindung 
- Auskunf tsdienste 
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- Videodienste 

- Telefonzusatzdienste, wie z.B. Konferenzen uber Konferenz- 
server 

- Mailboxabf ragen 

5 - anonymes Billing fur. Gateways, die aus dem offenen Inter- 
net angesteuert werden 
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Patentanspriiche 

1 . Dienstvermittlungseinrichtung^ die 

9 

a) von einem Client eine Dienstanforderung empfangt, 
5 b) daraufhin eine Authentifizierung durchfuhrt und dem Client 
nach einer erfolgreichen Authentifizierung eine Reference 
auf einen Application . Server zur Durchfiihrung des angefor- 
derten Dienstes mitteilt, 

c) von dem Application Server erstellte Vergebuhrungstickets 
10 empfangt , wobei die Tickets Inf ormationen hinsichtich der 

vor bzw. wahrend der Dienstnutzung anfallenden Gebuhren 
enthalten, 

d) beziiglich eines empfangenen Tickets jeweils eine Bestati- 
gungsanfrage an den Client richtet, 

15 e) fiir das Ticket einer Gebuhrenregistrierungsaktion durch- 
fuhrt, falls der Client das Ticket bestatigt. 

2. Dienstvermittlungseinrichtung nach Anspruch 1 
dadurch gekennzeichnet, 

20 dass die genannte Gebuhrenregistrierungsaktion darin besteht, 
dass die Dienstvermittlungseinrichtung den Guthabenstand oder 
Gebiihrenstand des Client aktualisiert . 

3 . Dienstvermittlungseinrichtung nach Anspruch 1 
25 dadurch gekennzeichnet, 

dass die genannte Gebuhrenregistrierungsaktion darin besteht f 
dass sie das Ticket zu einer spateren Rechungserstellung ab- 
speichert. 

30 4. Dienstvermittlungseinrichtung nach einem der Anspriiche 1 
bis 3, 

dadurch gekennzeichnet , 

dass sie dem Client die fiir die Gebuhrenregistrierungsaktion 
herangezogene Gebiihr mitteilt - 

35 
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5. Application Server , der 

a) von einem Client eine Dienstanf orderung empfangt, wobei 
die Dienstanforderung eine Reference auf eine Dienstver- 
mittlungseinrichtung enthalt, 

b) beziiglich des Dienstes Vergebiihrungs -Tickets erstellt und 
diese an die Dienstvermittlungseinrichtung sendet, wenn er 

... den Service-Request annimmt, wobei die Tickets Informatio- 
nen hinsichtich der vor bzw. wahrend der Durchfuhrung des 
Dienstes fur den Client fallig werdenden Gebuhren enthal- 
ten, 

c) von der Dienstvermittlungseinrichtung Mitteilungen daruber 
empfangt, ob die Tickets durch den Client bestatigt wer- 
den, 

d) die Durchfiihrung des Dienstes auf rechterhalt, solange die 
Tickets durch den Client positiv bestatigt werden. 

6. Application Server nach Anspruch 5, 
dadurch gekennzeichnet, 

dass er die Servicebeziehung zum Client beendet r wenn er von 
der Dienstvermittlungseinrichtung die Mitteilung empfangt, 
dass der Client eine Bestatigungsanf rage beziiglich eines Ti- 
ckets negativ quittiert hat. 

7. Application Server nach Anspruch 5 r 
dadurch gekennzeichnet , 

dass er die Servicebeziehung zum Client beendet, wenn er von 
der Dienstvermittlungseinrichtung die Mitteilung empfangt f 
dass der Client eine Bestatigungsanf rage bzw. mehrere Besta- 
tigungsanfragen beziiglich eines Tickets iiberhaupt nicht quit- 
tiert hat. 

8. Application Server nach Anspruch 5, 
dadurch gekennzeichnet , 

dass er die Servicebeziehung zum Client beendet, wenn er von 
der Dienstvermittlungseinrichtung iiberhaupt keine Quittung 
auf das von ihm generierte Ticket erhalt. 
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9. Application Server nach Anspruch 5, 
dadurch gekennzeichnet, 

dass er die Servicebeziehung zum Client beendet, wenn er von 
der Dienstvermittlungseinrichtung im Falle eines Prepaid- 
Nutzers beziiglich eines Tickets die Mitteilung erhalt, dass 
kein ausreichendes Guthaben mehr vorhanden ist. 

10. Client, der 

a) an eine Dienstvermittlungseinrichtung eine Dienstanforde- 
rung stellt, 

b) nach einer erfolgreichen Authentifizierung der Dienstan- 
forderung von der Dienstvermittlungseinrichtung eine Refe- 
rence auf den angef orderten Dienst empfangt, 

c) anhand der genannten Reference eine Servicebeziehung zu 
einem Application Server des angeforderten Dienstes auf- 
baut, 

d) von der Dienstvermittlungseinrichtung Bestatigungsanfragen 
beziiglich des Dienstes fallig werdender Gebuhren empfangt, 

e) die genannten Bestatigungsanfragen gegeniiber der Dienst- 
vermittlungseinrichtung verifiziert und beanwortet. 

11. Client nach Anspruch 10, 
dadurch gekennzeichnet, 

dass er die von der Dienstvermittlungseinrichtung mithilfe 
der Bestatigungsanfragen ubermittelten Gebiihrennachrichten 
kumuliert und diese Gebuhren dem Endnutzer zur Gebuhremiber- 
wachung in Realzeit anzeigt. 

12. Client nach Anspruch 10 Oder 11, 
dadurch gekennzeichnet, 

dass er es dem Endbenutzer erlaubt, eine Gebuhrennachricht 
manuell zu beantworten. 

13. Verfahren zur Vergebiihrung eines Dienstes in einem Kommu- 
nikationsnetz, demgemafi 

f ) von einem Client an eine Dienstvermittlungseinrichtung ei- 
ne Dienstanforderung gestellt wird, 
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g) daraufhin mithilfe der Dienstverxnittlungseinrichtung eine 
Authentifizierung durchgefiihrt wird, wobei dem Client von 
der Dienstvermittlungseinrichtung nach einer erfolgreichen 
Authentifizierung eine Dienst-Reference auf den angefor- 
derten Dienst mitgeteilt wird, 

h) von dem Client anhand der genannten Dienst-Reference eine 
Servicebeziehung zu einem Application Server des angefor- 
derten Dienstes aufgebaut wird, 

i) von dem Client dem Application Server eine Reference auf 
die Dienstvermittlungseinrichtung mitgeteilt wird, 

j) von dem Application Server Tickets erstellt und an die 
Dienstvermittlungseinrichtung gesendet werden, wobei die 
Tickets Informationen hinsichtlich der vor bzw. wahrend 
der Dienstnutzung anfallenden Gebuhren enthalten, 

k) von der Dienstvermittlungseinrichtung beziiglich eines Ti- 
ckets eine Bestatigungsanf rage an den Client gerichtet 
wird, 

1) falls das Ticket bestatigt wird, von der Dienstvermitt- 
lungseinrichtung das Ticket zu einer Gebiihrenregistrie- 
rungsaktion herangezogen wird. 

14. Verfahren nach Anspruch 13, 

dadurch gekennzeichnet, 

dass 

a) das Ergebnis der Bestatigungsanf rage von der Dienstver- 
mittlungseinrichtung an den Application Server weiterge- 
leitet wird, 

b) die Durchfuhrung des Dienstes seitens des Application Ser- 
vers aufrechterhalten wird, solange die Tickets durch den 
Client positiv bestatigt werden. 
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